メインコンテンツまでスキップ
バージョン: DAI 7.4

コンテナ内のEggplant DAIのデプロイ

ヒント

コンテナへのEggplant DAIのインストールを進める前に、組織内のエンジニアが認定Kubernetes管理者 (https://www.cncf.io/training/certification/cka/)であるか、同等の経験があることを確認する必要があります。

Eggplant DAIはHelmを使用してKubernetesにインストールできます 以下の要件を満たす必要があります：

要件注記
Kubernetes clusterバージョン1.27をテストしました。
ingress-nginxテスト済みのバージョン 1.10.0 (グラフ バージョン 4.10.0)。
Keda v2オプション、オートスケーリングエンジン用。 バージョン2.13.2をテストしました。
Eggplant DAI license必要に応じてサポートに問い合わせてください。

これらの要件を満たしたら、Helmの値ファイルを作成することで、デフォルトのEggplant DAIデプロイをインストールできます。 以下の例では、独自のデプロイ用にすべての値を置き換えます。

dai.yaml
global:
  postgresql:
    auth:
      postgresPassword: postgres
  ingress:
    host: dai.example.com
  keycloak:
    host: dai.example.com
  devLicense: a-real-license-goes-here
  execLicense: a-real-license-goes-here
  objectStorage:
    minio:
      rootUser: "eggplant"
      rootPassword: "eggplant"

keycloak:
  externalDatabase:
    # This must match the value of global.postgresql.auth.postgresPassword
    password: postgres

keycloak-user-provisioner:
  adminUsers:
    daiAdmin:
      username: admin-username
      email: admin-email
      password: admin-password

いくつかの注意点:

  • global.ingress.host と global.keycloak.host は同じドメインである必要はありませんが、解決可能である必要があります。 これを行うには、クラスターに ExternalDNS のようなものをデプロイするか、レコードを手動で作成してクラスターに向けます。
  • コンテナで実行する場合は、DAI を TLS と組み合わせて使用する必要があります。 TLS は、イングレスに証明書を追加することでクラスター内で終了するか、外部ロードバランサーで終了できます。 詳細については、以下の「TLS設定」セクションを参照してください。
  • global.ingress.host で設定するホスト名は、DAI専用に設定する必要があります。 同じサブドメインで他のアプリケーションを実行することはサポートされていません。
  • keycloak-user-provisioner.adminUsers.daiAdmin.password は12文字以上である必要があります。 keycloak-user-provisioner.adminUsersの下に追加のキーを追加することで、管理者ユーザーを追加できます。
  • DAI は、イングレス ルール内の構成スニペットを利用します 最新バージョンの ingress-nginx コントローラーを実行している場合は、これが allow-snippet-annotations に設定されていることを確認する必要があります。 これは、helm を使用して ingress-nginx をインストールする場合に controller.allowSnippetAnnotations をtrue に設定することで実現できます。

すべての値の詳細なドキュメントはこちらで見ることができます。

次に、Kubernetesクラスタにそれをデプロイします：

$ helm upgrade --install \
  --namespace dai \
  --create-namespace \
  dai \
  dai \
  --repo oci://harbor.dai.eggplant.cloud/charts/dai \
  --version 1.15.15 \
  --values dai.yaml \
  --wait
Release "dai" does not exist. Installing it now.
NAME: dai
LAST DEPLOYED: Fri Feb 17 08:20:17 2023
NAMESPACE: dai
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing dai.
リリースの名前は dai です。
リリースの詳細については、以下をお試しください。
$ helm status dai
$ helm get all dai
admin username: admin-username
admin password: admin-password

このインストールでは、Bitnami Helmチャートを使用して、必要なサードパーティの依存関係が自動的にインストールおよび設定されます。これらの依存関係は： These dependencies are: These dependencies are: これらの依存関係は以下の通りです：

依存関係テストされたチャートバージョンテストされたアプリバージョン
RabbitMQ11.13.03.11.13
PostgreSQL11.9.1314.7.0
MinIO12.2.62022.2.5
警告

Helmチャートはこれらの依存関係をインストールしますが、PostgreSQLまたはMinIOに格納されているデータのバックアップは管理しません。 これらのサービスのバックアップは、ディザスター リカバリー計画の一部として、運用デプロイに配置する必要があります。 バックアップの 1 つのアプローチの例は、このドキュメントの後半にあります。

サポートされているカスタマイズ​

デフォルトのインストールでは、PostgreSQLとMinIOのデータが永続ボリュームに保存され、すべての依存関係がKubernetesにデプロイされます。 PostgreSQLまたはAWS S3互換のオブジェクトストレージ用の既存のソリューションを代わりに使用したい場合は、Eggplant DAIのインストールをカスタマイズしてこれらを使用することができます。 さらに、セキュリティを向上させるために、値ファイルではなく Kubernetes シークレットを使用して資格情報を渡すこともできます。

ドキュメントのこのセクションでは、インストールをカスタマイズする方法を示す例を示します。 すべての例では、認証情報にシークレットを使用します。 すべての例は、上記で示したデフォルトのインストール値に追加することを意味するスニペットです。

オブジェクトストレージの設定​

Eggplant DAIは、テストスクリーンショットなどのアセットを永続的に保持するために、S3互換のオブジェクトストレージソリューションに依存しています。 Helm チャートには、これを構成するためのいくつかのオプションがあります

バンドルされたMinIO（デフォルト）​

デフォルトでは、Eggplant DAI Helmチャートはランダムなroot-userとroot-passwordでMinIOをサブチャートとしてデプロイします。

これらのランダムな値は、既存のシークレットを指定することでオーバーライドできます。 まず、次の資格情報を使用して既存のシークレットを準備します。

dai-objectstorage.yaml
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: dai-objectstorage
stringData:
  root-user: username
  root-password: password
$ kubectl -n dai apply -f dai-objectstorage.yaml

次に、既存のシークレットを指すように値ファイルを更新し、Helmアップグレードを実行します：

dai.yaml
global:
  objectStorage:
    minio:
      existingSecret: dai-objectstorage

minio:
  auth:
    existingSecret: dai-objectstorage
$ helm upgrade dai oci://harbor.dai.eggplant.cloud/charts/dai --version 1.15.15 -f dai.yaml --wait

注意：global.objectStorage.minio.existingSecret と minio.auth.existingSecret は一致する必要があります。

値ファイルの minio キーの下に値を渡すことで、MinIO インストールをさらにカスタマイズできます。 MinIOのインストールはBitnamiチャートによって提供されるため、利用可能なオプションについては、Bitnamiチャートのドキュメントを参照してください。

警告

Eggplantは、MinIOの設定の変更をサポートしていません。

既存のMinIO​

既存のMinIOインストールがある場合、上記で作成した同じシークレットを使用して、次のように使用できます：

dai.yaml
global:
  objectStorage:
    minio:
      existingSecret: dai-objectstorage
      endpoint: my.minio.deployment.example.com

minio:
  enabled: false

注： minio キーを使用して enabled を false に設定します。これにより、バンドルされたMinIOのデプロイが防止されます。 This prevents the bundled MinIO from being deployed. This prevents the bundled MinIO from being deployed.

警告

DAIインストールの外部のMinIOインストールに対して、Eggplantはサポートを提供できません。

S3​

AWS S3は、次のように既存のシークレットを使用してオブジェクトストレージに設定できます。まず、次の資格情報で既存のシークレットを準備します： First, prepare an existing secret with credentials in: First, prepare an existing secret with credentials in: まず、以下に認証情報を含む既存のシークレットを用意してください：

dai-objectstorage.yaml
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: dai-objectstorage
stringData:
  aws-access-key-id: my-access-key-id
  aws-secret-access-key: my-secret-access-key
$ kubectl -n dai apply -f dai-objectstorage.yaml

次のように、値ファイルを変更して、次のキーを更新または追加します。

dai.yaml
global:
  objectStorage:
    provider: "aws"
    aws:
      existingSecret: dai-objectstorage
      awsAccessKeyIdKey: aws-access-key-id
      awsSecretAccessKeyKey: aws-secret-access-key
      region: "eu-west-1"

minio:
  enabled: false

これで、Helm を使用してクラスターにデプロイできます。

PostgreSQL​

Eggplant DAIはデータストレージのためにPostgreSQLを使用しています。Helmチャートは、それを設定するためのいくつかのオプションを提供しています。 The Helm chart provides several options for configuring it. The Helm chart provides several options for configuring it.

バンドルされたPostgreSQL（デフォルト）​

デフォルトでは、Eggplant DAI Helmチャートはユーザー名とパスワードの両方を postgres に設定して、PostgreSQLをサブチャートとしてデプロイします。

これを上書きするには、次の資格情報でシークレットを作成します：

dai-postgres.yaml
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: dai-postgres
stringData:
  postgres-password: my-access-key-id

値ファイルを変更して次のキーを更新または追加し、Helm を使用してクラスターに適用します。

dai.yaml
global:
  postgresql:
    auth:
      existingSecret: dai-postgres

keycloak:
  externalDatabase:
    existingSecret: dai-postgres
    existingSecretPasswordKey: postgres-password

注 'keycloak.externalDatabase.existingSecretPasswordKey': デフォルトでは、Bitnami チャートは既存のシークレットがキー 'password' の下にデータベース パスワードを持つことを期待していますが、Bitnami PostgreSQL チャートと DAI はデフォルトでキーとして 'postgres-password' に設定されています。 上記のようにKeycloakチャートの動作を上書きするか、または「global.postgresql.auth.secretKeys.adminPasswordKey」を設定することができます。

PostgreSQLのインストールはBitnamiチャートによって提供されています。postgresqlキーの下でvaluesファイルにオプションを渡すことで、さらにカスタマイズすることができます。利用可能なオプションについては、Bitnamiのドキュメントを参照してください。 値ファイルの postgresql キーの下にオプションを渡すことで、さらにカスタマイズできます。 See the Bitnami documentation for available options.

'extraEnvVars' をオーバーライドする場合は、'POSTGRESQL_DATABASE' 環境変数も 'keycloak' に設定する必要があります。 これにより、デフォルト値の「keycloak」キーの下に設定されたKeycloakデータベースが作成されます。

警告

EggplantはPostgreSQLの設定の変更をサポートしていません。

既存のPostgreSQL​

既存のPostgreSQLのインストールがある場合、またはAWS RDSのような外部サービスを使用したい場合は、それを行うことができます。

上記と同じ既存の秘密を使用して、次のキーを設定するようにvaluesファイルを変更します：

dai.yaml
global:
  postgresql:
    host: my.postgresql.host.example.com
    auth:
      existingSecret: dai-postgres

keycloak:
  externalDatabase:
    existingSecret: dai-postgres
    existingSecretPasswordKey: postgres-password
    host: my.postgresql.host.example.com

postgresql:
  enabled: false

既存のPostgreSQLデプロイメントを使用する場合、これを使用するようにKeycloakの設定も更新する必要があります。

エンジンのスケーリング​

Eggplant DAIのエンジンコンポーネントは、テストの実行とレポートの生成に使用されます。DAIインスタンスが忙しくなると、このコンポーネントをスケーリングして、より大きなテストボリュームを処理する必要があります。このスケーリングを管理するためにKedaを使用することをお勧めします。 DAI インスタンスがビジーになると、このコンポーネントをスケーリングして、より多くのテスト量を処理する必要があります。 このスケーリングを管理するには、Kedaを使用することをお勧めします。

Kedaを使用するには、まずupstream instructionsに従ってインストールします。

ヒント

サポートされているのはKeda v2のみです。

次に、valuesファイルに以下を追加してKedaを有効にします：

dai.yaml
ai-engine:
  keda:
    enabled: true

何らかの理由でKedaを使用できない場合、以下をvaluesファイルに追加して、エンジンレプリカの数を手動で管理することができます。イ ンスタンスが忙しくなるにつれて、それを増やします。

dai.yaml
ai-engine:
  replicaCount: 2

Keycloak​

Eggplant DAI は、認証および承認サービスに Keycloak に依存しています。 これはサブチャートとしてバンドルされており、現在、独自のKeycloakインストールの使用はサポートされていません。

Configuring TLS​

コンテナでDAIを実行する場合、TLS証明書の使用は必須です ただし、DAI バージョン 7.3 以降では、プライベート認証局によって署名された TLS 証明書を使用できます (以下の「カスタム TLS 認証局 (CA) の追加」(#adding-a-custom-tls-certificate-authority-ca) セクションを参照)。 TLSをどのように追加するかはユーザー次第であり、インフラストラクチャに依存する可能性があります これには、次のものが含まれます。

  • クラスタの外部にあるロードバランサーに TLS 証明書を追加し、そこで TLS 接続を終了する
  • Ingress-nginx コントローラーにワイルドカード証明書を追加して、すべての ingress ルール/ホストが共通の証明書を共有できるようにする
  • TLS 証明書を含む Kubernetes シークレットを DAI 名前空間に追加し、シークレットの詳細を値を介して DAI に提供します。

最初の 2 つのオプションはインフラストラクチャによって異なり、DAI 構成を変更する必要はありません。 DAIにTLS証明書を追加する場合は、次のことができます。

  1. 証明書とキーを PEM 形式で取得します。 証明書には、完全なチェーンが含まれている必要があります。

  2. DAI 名前空間に TLS を作成します。 (最初に名前空間を作成する必要がある場合があります)。

    kubectl create secret tls tls-secret --cert=path/to/cert/file --key=path/to/key/file -n dai

  3. DAI helm 値ファイルの ingress セクションを更新して、以下のように 'global.ingress' と 'global.keycloak' の下に 'tls' セクションを追加します (ホスト名とシークレット名をインストールに合わせて更新してください)。

    dai.yaml
    global:
      ingress:
        host: dai.example.com
        tls:
          - hosts:
            - dai.example.com
            secretName: tls-secret
      keycloak:
        tls:
          secretName: tls-secret

  4. 通常どおり Helm のインストールを完了します。

カスタム TLS 認証局 (CA) {#adding-a-custom-tls-certificate-authority-ca} の追加​

個々の DAI サービスは、リクエストの認証と承認に Keycloak を使用します。 これには、サービスが Keycloak エンドポイントに到達できる必要があります (構成されている TLS 証明書の検証を含む)。 DAI の各リリースには最新の CA 証明書が付属しており、ほとんどの公的に署名された証明書を検証できます。 DAI インスタンスが設定された TLS 証明書を確認できない場合は、「global.ingress.customCACert」値を設定することで、helm 値を介して関連する CA を提供できます。

次のスニペットの例は、DAI に追加されるプライベート CA 証明書を示しています。 これにより、CA によって署名された TLS を DAI で使用できるようになります。

dai.yaml
global:
  ingress:
    host: dai.example.com
  customCACert: |
    -----BEGIN CERTIFICATE-----
    MIIFYDCCA0igAwIBAgIJAL6zT1uUli/yMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
    BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
    aWRnaXRzIFB0eSBMdGQwHhcNMjQwNDEwMTQ0NTU3WhcNMjkwNDA5MTQ0NTU3WjBF
    MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
    ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC
    CgKCAgEAyP3ve0Y3Y9Wh0G6dxWGQSdOPzVRgzv2adUV763GQOiEnSy8Z44X9rYNS
    s6Yd80H5hDuHFPPTHeQdOQ+BVFlUqKT1nsVzDwwy9eApHLRiv3CXKE749sqRiFiQ
    PwEGxk2zjRqOFm2phFKY81ikdazjd9Kl9bfdALrmJk6vFCHV3bwIgOFlkl42nWT+
    cAnjZEo4p9pejKyccC/43L/BiVZ3ILYKmAhtQFgtBfX0STlV1eqvr0tKOU1WcHdb
    AkUoWgmymEAqKOTgF3mptjeg2a+lAaXPMD25vUI5OZ3Kn+kGoL2bRM/3ujQdwv+0
    reSvah2+XmJHeaGA3Mr00IGJF85H9YQDgrU9/nvJQX0NyDjO9Z4qViROU40nCMrf
    41cBmD9e5DZL5bSyhAiNlbq0MplIvm2ervlvou6ymPfVkQmdet5rGNe3+XOFbamc
    c2j65tgUm6+KSoho7xi+3PvmRDwgplTKLavcdZMHxjVWp6gQm6PVOxrheII+ZuIS
    Au3ixVaN4anPRlV02EvkBu8Hf67faL6sL65kTYkL98BSdpIepJkHEBONv9DuCH9g
    5jiGHXPyBkMuga7uxF6OTVR/SHd+io0ookbUyfuSIWywBBHvDu0cJG8CmrdptzCv
    YBGg7fjz8IOrawOdv/3VVEzixe+qVr3HFT+eO3MMf9eNCo7M7U8CAwEAAaNTMFEw
    HQYDVR0OBBYEFKSpIbnsb6Fff2dbiJYxLrtiyoGKMB8GA1UdIwQYMBaAFKSpIbns
    b6Fff2dbiJYxLrtiyoGKMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQAD
    ggIBAJD/rb1XpIXchX58dG6AV+uPtZ7ek1kqJHTA6fHW7UchZrtXW27HCraPnZ9m
    hN/iiXxyflPWQFpndAWA3Zzor3eKZMPek5DvXa5yosC/2/kRlw+GkIXhrJEKvOaM
    tIOXgKMuwZyLsYV5PD1Y3J1q+jx58euiZtsQRIDM8K7BuzmMruvWGXzxT2Vm54ZS
    6s597X2YKlSu/34+G9a/8N9OqiULp+k0QKz/DXOpWXk8q9u95Ga2WExfsSH8H+ZW
    2swVt9shdH5/L7Jbpm9Kq1acyI9WPh9oXDsGIcoWh10zblgqajIMzYX22tHjJc7M
    GcoLubn9sSkJgqP46IfOngmbH2Ik9mDylXl11LPgrw8XudMh/Uf5RkvsJX9tAmib
    IHrM2n0tSQiuZA16suABvGsmQkdhBzhFnpZJfgmxVXnEmwU8k2cUByil09ZoKtYw
    7YvMz+p+uFdl+uoOhWOLbfSftymMkeHNRdykiNCXqCjPzZgHVwHCCIPIDWpIbb7w
    qkzoUw6dp1YOz4RO0ZsJ7zhztSsSGHinvbH1TnXzdCj1OjkP612/lRJB3NC99rbg
    HFKMUeiXEtZbMtTYaBxJ9vWxtkbeVwaWZommZVjDk6kYFiUsShij9olN78JcZB6/
    2TxFcGsToiq0hJQ19soqTKuBP79TCpeQpOQj/glYB8MZbU+R
    -----END CERTIFICATE-----

ノードセレクタの設定​

ノードセレクターは、Helm値を介して追加し、DAIサービスを実行するKubernetesノードを制御できます。 すべてのDAIサービスのノードセレクターを設定するには、値にglobal.dai.nodeSelector を設定します。 DAI はサードパーティのコンポーネントも使用するため、これらは値ファイル内で個別に設定する必要があります。 以下の例のスニペットは、ノードセレクターが、すべてのDAIサービスおよびPostgresql、Rabbitmq、Minio、およびKeycloakサブチャートで「node-pool=application」というラベルのノードのみを使用するように設定できることを示しています。

dai.yaml
global:
  dai:
    nodeSelector:
      node-pool: application

postgresql:
  primary:
    nodeSelector:
      node-pool: application

rabbitmq:
  nodeSelector:
    node-pool: application

minio:
  nodeSelector:
    node-pool: application

keycloak:
  nodeSelector:
    node-pool: application

バックアップと復元​

DAI インストールからの構成データと結果データを定期的にバックアップする必要があります。 バックアップが必要なデータは、PostgreSQL(DAIおよびKeycloak用に構成) とオブジェクトストレージに保存されます。

このデータのバックアップ方法は、デプロイメントの設定方法によって異なりますが、ここでは、このドキュメントの冒頭に示されているデフォルトのインストールで両方をバックアップする方法の例を示します。

PostgreSQLのバックアップと復元​

Eggplant DAIは複数のデータベースを使用してデータを保存するため、すべてのデータベースを確実にバックアップするために、デフォルトのインストールでは「pg_dumpall」を使用することをお勧めします。 共有データベースインスタンスを使用している場合は、次のデータベースをバックアップする必要があります。

  • execution_service
  • keycloak
  • sut_service
  • ttdb
  • vam

以下の例では、デフォルトのPostgreSQLポッド内でpg_dumpallを直接実行します。結果は、ローカルコンピューターのdai.dumpファイルにストリームされます： 以下の例では、デフォルトのPostgreSQLポッド内でpg_dumpallを直接実行します。結果は、ローカルコンピューターのdai.dumpファイルにストリームされます： The result is then streamed to dai.dump file on the local computer: その後、結果はローカルコンピュータ上の 'dai.dump' ファイルにストリーミングされます。

$ kubectl --namespace dai exec postgres-0 \
  -- /bin/sh -c \
  'export PGPASSWORD=$POSTGRES_PASSWORD && pg_dumpall --username postgres --clean' \
  > dai.dump
警告

The command given here includes the --clean option. これにより、'pg_dumpall' には、ダンプ内のデータベースを削除するコマンドが含まれます。 これにより復元が容易になりますが、これが発生することを知っておく必要があります。

実際には、次のことをしたいでしょう：

  • ダンプを圧縮する
  • バックアップストレージサーバーに配置する
  • スケジュールに従って実行する。

ただし、pg_dumpallの使用はそのまま維持されます。

バックアップを復元するには、次のようにプロセスを反転させることができます：

$ kubectl --namespace dai exec postgres-0 \
  -- /bin/sh -c \
  'export PGPASSWORD=$POSTGRES_PASSWORD && psql --username postgres \
  --dbname postgres \
  --file -' < dai.dump

いくつかの注意点：

  • -We used the --clean option when creating the dump. これは、バックアップ内のすべてのデータベースが削除され、再作成されることを意味します。
  • -We specify --dbname postgres. バックアップは '--clean' で作成されているため、復元の一部としてドロップされるデータベースの 1 つに接続するとエラーが発生します

MinIOのバックアップと復元​

画像やその他のアセットは、データベースではなくオブジェクトストレージに保存されます。 上記で説明したデータベースの内容に加えて、これらをバックアップする必要があります。 このバックアップをローカル マシンから実行する簡単な方法を以下に示します。 次の例では、MinIOクライアントツールをローカルにインストールする必要があります。

$ ROOT_USER=$( kubectl get secret dai-objectstorage -o json | jq -r '.data."root-user"' | base64 -d )
$ ROOT_PASSWORD=$( kubectl get secret dai-objectstorage -o json | jq -r '.data."root-password"' | base64 -d)
$ kubectl port-forward service/minio 9000:9000 &
$ PID=$!
$ mcalias set minio <http://localhost:9000> $ROOT_USER $ROOT_PASSWORD -api S3v4
$ mkdir backup
$ mc cp --recursive --quiet minio/ backup/
$ kill $PID

前回と同様に、バックアップを圧縮し、適切なストレージサーバーに移動して、スケジュールに従って実行することをお勧めします。

バックアップを復元するには、コピーコマンドを逆にするだけです：

$ mc mb minio/assets
$ mc mb minio/screenshots
$ mc cp --recursive --quiet backup/ minio/

これは、デフォルトの設定でアセットバケットとスクリーンショットバケットを分けて使用していることを前提としています。その場合は、復元する前に「mc mb」でバケットを作成する必要があります。

アップグレード​

アップグレードの一般的な手順は、任意のHelmリリースと同じです：

  • PostgreSQLデータとオブジェクトストレージデータをバックアップします。
  • 1.PostgreSQLとオブジェクトストレージのデータをバックアップします。 2.helm repo updateでリポジトリを更新します。 3.バンドルされたMinioを使用している場合、Minioのデプロイメントのルートユーザーとパスワードを取得します。 4.Keycloakのデプロイメントのルートユーザーとパスワードを取得します。 5.既存の値を取得し、必要な新しい値に変換します。 6.helm uninstall -n dai daiで古いデプロイメントをアンインストールします。 7.さらに、kubectl -n dai delete jobs --all && kubectl -n dai delete pvc --allで古いPVCとジョブをすべて削除します。 8.次のようにしてHelm 6.5のリリースをインストールします：
  • helm get valuesとテキストエディターで新しいリリースの必要に応じて値を変更します。
  • helm upgradeを実行します。

Each Eggplant DAI release may have specific additional steps. そのため、この手順を適用する前に、実行しているアップグレードについて以下の注意事項を確認してください。

DAI 7.3 から 7.4 へのアップグレード​

上記の一般的なガイダンス以外に、7.3 から 7.4 へのアップグレードに従う特定の手順はありません。

DAI 7.2 から 7.3 へのアップグレード​

上記の一般的なガイダンス以外に、7.2 から 7.3 へのアップグレードに従うべき特定の手順はありません。

DAI 7.1 から 7.2 へのアップグレード​

上記の一般的なガイダンス以外に、7.1 から 7.2 へのアップグレードに従うべき特定の手順はありません。

DAI 7.0 から 7.1 へのアップグレード​

7.0から7.1へのアップグレードについては、上記の一般的なガイダンスの他には、具体的な手順はありません。

DAI 6.5 から 7.0 へのアップグレード​

DAI 7.0 のリリースには、以前のバージョンと互換性のないMinioのアップデートが含まれています。 バンドルされたMinioをオブジェクトストレージに使用している場合は、古いMinioインストールをバックアップし、DAIのアップグレード後にデータを復元する必要があります。

  • -上で説明されているように、現在のMinioのインストールをバックアップします。 -現在のMinioのデプロイメントとPVCを削除します。 現在のMinioのデプロイメントとPVCを削除します。 kubectl delete pvc -l app.kubernetes.io/name=minio --wait=false && kubectl delete deployment -l app.kubernetes.io/name=minio -Review values and run helm upgrade.

  • 現在のMinioのデプロイメントとPVCを削除します。

    kubectl delete pvc -l app.kubernetes.io/name=minio --wait=false && kubectl delete deployment -l app.kubernetes.io/name=minio

  • 値を確認し、helm upgradeを実行します。 これにより、他のDAIコンポーネントをアップグレードすると同時に、Minioのクリーンなインストールが作成されます。

  • 上で説明されているように、既存のMinioデータを新しいMinioデプロイメントに復元します。

DAI 6.4 から 6.5 へのアップグレード​

DAI 6.5は、以前のリリースと互換性のない新しいHelmチャートを導入します。 したがって、このリリースで推奨されるアップグレード手順は異なります。

  1. PostgreSQLとオブジェクトストレージのデータをバックアップします。
  2. -PostgreSQLデータとオブジェクトストレージデータをバックアップします。 -helm repo updateでリポジトリを更新します。 -helm get valuesとテキストエディターで新しいリリースの必要に応じて値を変更します。 -helm upgradeを実行します。
  3. バンドルされたMinioを使用している場合、Minioのデプロイメントのルートユーザーとパスワードを取得します。
  4. Keycloakのデプロイメントのルートユーザーとパスワードを取得します。
  5. 既存の値を取得し、必要な新しい値に変換します。
  6. helm uninstall -n dai daiで古いデプロイメントをアンインストールします。
  7. さらに、kubectl -n dai delete jobs --all && kubectl -n dai delete pvc --allで古いPVCとジョブをすべて削除します。
  8. 次のようにしてHelm 6.5のリリースをインストールします：
helm install -n dai dai eggplant/dai --version 1.3.4 -f new-values.yaml --wait

バンドルされたMinioを使用している場合、バックアップからデータを復元します。

正確なプロセスは、以前のデプロイによって異なる場合があります。 リソースを削除する前にバックアップを確認し、正しいリソースを削除するように注意してください。

チャートの残りのドキュメントを確認して新しい値ファイルを作成することをお勧めしますが、以下は、6.5より前の値ファイル内のキーから6.5+値ファイル内のキーの位置へのマッピングです。 これは完全な値のリストではなく、移動した値のリストのみです。 ただし、値に関するドキュメントを確認して、必要なすべてのキーを設定し、それらが正しく設定されていることを確認する必要があります。

Old KeyNew Key
global.adminusernamekeycloak-user-provisioner.adminUsers.daiAdmin.username
global.adminEmailkeycloak-user-provisioner.adminUsers.daiAdmin.email
global.adminPasswordkeycloak-user-provisioner.adminUsers.daiAdmin.password
global.licenseglobal.devLicense, global.execLicense
externalDatbaseglobal.postgresql
externalBrokerglobal.rabbitmq
objectStorageglobal.objectStorage
ingress.hostnamesglobal.ingress.host
ingress.tlsglobal.ingress.tls
keda.enabledai-engine.keda.enabled
keycloak.realmglobal.keycloak.realm
keycloak.urlglobal.keycloak.host
keycloak.adminUserglobal.keycloak.user
keycloak.adminPasswordglobal.keycloak.password
keycloak.smtpkeycloak-realm-provisioner.smtp

DAI 6.3 から 6.4 へのアップグレード​

DAI 6.4 のリリースには、Keycloakの内部バージョンがバージョン19に更新されています。この新しいバージョンにアップグレードするには： To upgrade to this new version: To upgrade to this new version: この新しいバージョンにアップグレードするには：

  • yamlファイルを編集して、keycloak.adminPasswordキーをkeycloak.auth.adminPasswordに移動します。
  • デフォルトの管理ユーザー名を使用していない場合、keycloak.adminUserキーをyaml内のkeycloak.auth.adminUserに移動します。
  • -yamlファイルを編集して、keycloak.adminPasswordキーをkeycloak.auth.adminPasswordに移動します。 -デフォルトの管理ユーザー名を使用していない場合、keycloak.adminUserキーをyaml内のkeycloak.auth.adminUserに移動します。 -The helm upgrade process deploys a new StatefulSet which is incompatible with the existing StatefulSet. helmのアップグレードプロセスは、既存のStatefulSetと互換性のない新しいStatefulSetをデプロイします。したがって、helmのアップグレードを実行する前に、元のStatefulSetを削除する必要があります（このステップが完了すると、DAIインスタンスは6.4へのアップグレードが完了するまでアクセスできなくなります）：
$ kubectl delete statefulsets.app -l app.kubernetes.io/name=keycloak --namespace dai

DAIバージョン 6.2 から 6.3 へのアップグレード​

  • KEDA を使用している場合、v1 はサポートされなくなりました。 KEDAを使用している場合、v1はサポートされていません。DAIをアップグレードする前にKEDA v2にアップグレードする必要があります。これを行うには、KEDAをアップグレードする前にai-engineジョブを削除することを確認してください。 In order to do this, make sure you remove the ai-engine job before upgrading KEDA. これを行うには、KEDA をアップグレードする前に 'ai-engine' ジョブを削除してください。
$ kubectl -n dai delete job ai-engine

DAIバージョン 5.3 から 6.0 へのアップグレード​

  • サービス トークンと JWT シークレットを設定する必要がなくなりました。 これらの値を削除します。
  • Helm チャートは、Keycloak インスタンスを他の DAI コンポーネントと同じ名前空間にデプロイします。 ただし、Keycloak URL は https://kc-<ingress-hostname>(<ingress-hostname> は値ファイルで指定したParameterー値) を指定する必要があります。

アンインストール​

Eggplant DAIをhelm uninstallでアンインストールするか、それをインストールした名前空間を削除することでアンインストールできます。

PostgreSQL インスタンスや S3 バケットなどの外部リソースを使用するためにカスタマイズを適用した場合は、これらを個別に削除する必要があります。

値​

完全なドキュメントは、Eggplant DAIチャートでサポートされているすべての値を示しています。

サポート​

さらなるサポートが必要な場合は、Eggplantカスタマーサポートに連絡してください。

に最終更新